fix(tests): restore collection and repair stale test imports (task-coding-0007) - #5

What this fixes, and what it deliberately does not

Four focused commits, 31 insertions / 13 deletions across 7 files, all under tests/. No product code changed.

The blocker, reproduced independently

I ran this myself in a clean clone. On unmodified master:

E   ModuleNotFoundError: No module named 'run_orchestrator'
Interrupted: 1 error during collection
1 error in 0.14s

The entire session dies in 0.14 seconds. Over 13,000 tests were never collected. That is what continue-on-error: true on the test job has been concealing.

The suite is NOT green, and that is the honest outcome

My own run on this branch: 45 failed, 13400 passed, 60 skipped, 7 errors. The handoff reports 45 failures and 7 errors for pytest tests/ -v --tb=short, which matches; its 39/13256 figure is from a different invocation, and my pass/skip counts differ slightly from that one because my venv resolved some optional dependencies differently. Both agree on what matters: not green.

What changed is nevertheless the whole point of stage 1: the masking now conceals a measured, itemised 45+7 instead of an unknown behind an abort that executed zero tests.

The session also confirmed task-coding-0006's baseline by re-measuring rather than trusting it: 49 failed / 13242 passed / 55 skipped / 9 errors at 352a858 — exactly as reported.

Judgment worth highlighting

Before choosing the repair, the session measured what the alternative would cost — via PYTHONPATH rather than an edit: tests/orchestrator yields 24 failed, 126 passed, 5 skipped. That measurement ruled out retiring the directory into _archive/old_tests/, even though that is the repository's own precedent from the very same commit (aa41933), because it would have thrown away 126 passing tests. Checking the cost of deletion before deleting is exactly right.

No test was weakened, skipped, xfail-ed or deleted to reach a nicer number.

What remains, itemised rather than summarised

39 of the 52 remaining items are genuine product defects and were deliberately not fixed — per-item evidence in §3.2 of the handoff, with ten follow-ups proposed as CE-1..CE-10.

The highest-priority one is worth stating here: the entire src/engine/validators/ package is unimportable in a fresh clone. All eight modules do from src.engine.validators import SpecValidator, SpecValidator is defined nowhere in the repository, and no __init__.py is tracked because .gitignore swallows it.

13 items are environment or dependency artefacts, not code findings. Chief among them a real pin conflict: requirements.txt:4 pins pydantic==2.10.3, but autogen-ext[mcp]>=0.5 needs mcp>=1.11.0 which needs pydantic>=2.11 — so pip resolves back to autogen-ext 0.4.5, whose tools/ has no mcp submodule, breaking 4 items. Meanwhile CLAUDE.md documents the intended version as autogen-agentchat 0.7.5. Verified with pip install 'autogen-ext[mcp]==0.7.5' --dry-run, which wants pydantic 2.13.4.

Consequence for stage 2

task-coding-0008 cannot un-mask the test job. Doing so would make CI permanently red — the exact outcome the staging exists to prevent. I will re-scope it and put the product defects to the user rather than quietly widening a routine task into them.

Evidence

• docker compose config → exit 0, and likewise for the customer-deploy and fungus compose files. docker-validate remains the only blocking CI job and it is green
• superproject pytest tests/v1_governance -q → 257 passed
• session validate → approved, run against the request on master — the predecessor blocker from 0034/0006 did not recur, because the admission merged first this time
• audit → dirty_paths [], submodule never initialized; git status --short empty in both worktrees. Isolation: real git worktree in both repositories

coding-engine/la_fungus_search still pins the dangling f731c19a — excluded by user decision, not touched, no recursive init attempted.

Generated by Claude Code